The proliferation of network computing has transformed business and personal communication. The flow of information between computers continues to increase. Accompanying this increased flow of information is a concern for network security. Commercial users, who exchange confidential or company proprietary information, demand that such information is secure against interception by an unauthorized party or to intentional corruption. Participants in electronic commerce over the global Internet recognize the critical role cryptographic systems play in maintaining secure communication.
One network application that is growing in popularity is Internet Protocol (IP) multicasting, which is a bandwidth conserving technology that reduces traffic by simultaneously delivering a single stream of information to thousands of recipients. Applications that take advantage of multicast include video conferencing, corporate communications, distance learning, and distribution of software, stock quotes, and news. Historically, these applications have been run by two inefficient schemes—unicasting and broadcasting. In unicasting one copy of data is sent to each receiver. While unicasting is a simple mechanism for one-to-one communication, for one-to-many communication it causes network congestion due to its huge bandwidth demands. In broadcasting a single copy of data is sent to every user in the network, solving the bandwidth problem. However, it is not suitable if only few receivers have requested the data.
IP Multicast solves the inherent bottlenecks created when a sender needs information transferred from a single sender to multiple recipients. By sending only one copy of the information to the network and letting the network intelligently replicate the packet only where it needs to, bandwidth and network resources are conserved both on the sending and the receiving end of a transmission. However, IP Multicast requires secure management of content communication channels and the addition and deletion of members of a multicast group. In addition, IP Multicast requires knowledge of and effective use of many supporting technologies and higher-level protocols. For example, dynamic registration using Internet Group Multicast Protocol (IGMP) is required at the LAN side. For multicast forwarding, protocols such as Distance Vector Multicast Routing Protocol (DVMRP), Multicast extensions to OSPF (MOSPF), and Protocol-Independent Multicast (PIM), are used. An example of a commercial application that uses one or more of these facilities to implement multicasting is Microsoft NetShow.
However, security management and multicast address assignment are not inherently provided by these mechanisms. There is no protocol akin to Secure Sockets Layer (SSL) for carrying out security and no protocol akin to DHCP for carrying out address assignment. There is a need to provide such mechanisms for multicast.
Cryptography is the art and science of keeping messages secure. A message is information or data that is arranged or formatted in a particular way. In general, a message, sometimes referred to as “plaintexf” or “cleartext,” is encrypted or transformed using a cipher to create “ciphertext,” which disguises the message in such a way as to hide its substance. In the context of cryptography, a cipher is a mathematical function that can be computed by a data processor. Once received by the intended recipient, the ciphertext is decrypted to convert the ciphertext back into plaintext. Ideally, ciphertext sufficiently disguises a message in such a way that even if the ciphertext is obtained by an unintended recipient, the substance of the message cannot be discerned from the ciphertext.
Many different encryption/decryption approaches for protecting information exist. For example, for small applications that require a relatively low level of security, a traditional restricted algorithm approach may be appropriate. With a restricted algorithm approach, a group of participants agree to use a specific, predetermined algorithm to encrypt and decrypt messages exchanged among the participants. Because the algorithm is maintained in secret, a relatively simple algorithm may be used. However, in the event that the secrecy of the algorithm is compromised, the algorithm must be changed to preserve secure communication among the participants. Scalability, under this approach, is an issue. As the number of participants increases, keeping the algorithm secret and updating it when compromises occur place an undue strain on network resources. In addition, standard algorithms cannot be used since each group of participants must have a unique algorithm.
Other approaches use a key-based algorithm. Generally two types of key-based algorithms exist: (1) symmetric algorithms and (2) asymmetric algorithms, of which one example is a public key algorithm. A key forms one of the inputs to a mathematical function that is used by a processor or computer to generate a ciphertext.
Public key algorithms are designed so that the key used for encryption is different than the key used for decryption. These algorithms are premised on the fact that the decryption key cannot be determined from the encryption key, at least not in any reasonable amount of time with practical computing resources. Typically, the encryption key (public key) is made public so that anyone, including an eavesdropper, can use the public key to encrypt a message. However, only a specific participant in possession of the decryption key (private key) can decrypt the message.
Public key algorithms, however, often are not employed as a mechanism to encrypt messages, largely because such algorithms consume an inordinate amount of system resources and time to encrypt entire messages. Further, public key encryption systems are vulnerable to chosen-plaintext attacks.
As a result, a public key cryptosystem generally is utilized to establish a secure data communication channel through key exchanges among the participants. Two or more parties, who wish to communicate over a secure channel, exchange or make available to each other public (or non-secure) key values. Each party uses the other party's public key value to privately and securely compute a private key, using an agreed-upon algorithm. The parties then use their derived private keys in a separate encryption algorithm to encrypt messages passed over the data communication channel. Conventionally, these private keys are valid only on a per communication session basis, and thus, are referred to as session keys. These session keys can be used to encrypt/decrypt a specified number of messages or for a specified period of time. A session can refer to a period of time in which a specified set of clients participate in a multicast group.
Once a multicast group is established, management of the session keys after group membership changes poses problems. Forward secrecy, which arises when a member node leaves the multicast group and may still possess the capability to decipher future messages exchanged among the group, becomes a concern. In addition, in the case where a new member node enters the multicast group, the new member should not be permitted to decrypt the past messages of the multicast group. Another consideration involves making session key updates when a multicast “join” or “leave” occurs; updates must be rapid to prevent undue system delay so that the network scales to accommodate additional users.
Another conventional technique used to establish secure communication employs a trusted third party authentication mechanism, such as a certificate authority (“CA”) or key distribution center (“KDC”) to regulate the exchange of keys. FIG. 9 is a block diagram of a system that uses a single central group controller (GC) 901 that has responsibility for distributing, creating, and updating session keys to members of a multicast group comprising users A-H. The eight users, A-H, communicate with group controller 901 via separate point-to-point channels or connections 903 to obtain a dynamic group session key. The connections 903 can be made secure by using a standard Diffie-Hellman key exchange protocol. Group controller 901 may be, for example, a router that uses IGMP and related protocols to manage multicast applications.
The group controller preferably determines or comes to a shared group session key using a binary tree approach as described herein. The KDC or CA carries out a third party authentication. The keys can be sent in a multicast or broadcast messages or overlapping broadcast or multicast messages or many point to point messages. In an embodiment, the authentication occurs over a point-to-point secured channel. The updated group session key can only be sent to the new member over the secured channel, which is point to point. The same key can also be sent to other trusted member KDCs or CAs over an out-of-band and orthogonal secured multicast or broadcast group, and it is assumed that such group has previously built a secured channel with different means.
Diffie-Hellman is not required to secure communications with the group controller, as the binary tree approach provides it. For point-to-point communication, a unicast version of Diffie-Hellman can be used. A group controller could use a multicast version of Diffie-Hellman, although it treats every member as a peer and GC is only required for authenticating members but is also a permanent member) as well as the Binary Tree Algorithm. If it is communicating to each member point to point, it can as well use any arbitrary mechanism to come to a Group Session Key and send it individual members. Multicast version of Diffie-Hellman and the Binary Tree methods are for multicast or broadcast nature of exchanges, where Multicast version needs no central authority (except for the need to authenticate as well) and the Binary Tree method needs a central authority as GC.
Ideally, only one message from the group controller is needed. Alternatively, Diffie-Hellman is used to do a point to point communication with the CA or KDC, and the CA or KDC can give out a group session key without using the binary tree approach. All nodes get the same session key using N−1 point to point messages, where “N” represents the number of multicast group members. These two approaches are orthogonal and can be combined for optimization.
To set up the secured channel among the nodes, N−1 messages are exchanged, wherein N is the number of nodes. A major drawback of this approach is that the group controller 901 represents a single point of failure, and therefore the system lacks fault tolerance. If the group controller 901 is down, no secure communication can exist among the multicast group of users A-H. Such a prospect is unacceptable, especially in mission critical systems.
Another drawback is that the group controller 901 is a potential bottleneck in the network when a binary tree algorithm is used, and the KDC or CA are potential bottlenecks when other mechanisms are used. For instance, if multiple nodes request to join the multicast group, the group controller 901 may not be able to process all such requests in a timely manner. This problem may be acute if the multicast group is over a wide area network (WAN). Further, a system dependent upon a group controller 901 is not easily enlarged or scaled, due, in part, to physical hardware constraints.
Accordingly, there is a clear need for improved approaches to setting up and managing multicast groups.
In particular, there is a need for a way to carry out secure, scalable multicast key distribution at the LAN level. If more than one multicast key distribution agent is used, there is a need to provide a secured channel among the distributed multicast key distribution agents at the LAN level.
There is also a need for a way to provide improved utilization of multicast key distribution agents at the WAN level. A particular need is achieving near perfect forward security and near perfect backward security in each key distribution node.
There is also a need for a way to reduce the overhead involved in calculating new keys.